Vertical Menus
Overview
Asset Lifecycle Information Management can render vertical menus for relationship templates that are defined an instance’s class and some other object type classes. For example, below is a vertical menu on the left side of the Assets tab for a Document instance:
The concept is that vertical tabs represent templates that have been defined for relationship classes that have the current instance’s class (in this case Document class) as a part of the attribute domain definitions on one side (left side) and classes of another object type (in this case Tag Object) on the other side of the attribute domain definition (right side).
A template can be configured that will display in the right pane when a relationship template is selected in the vertical menu. Typically, it is a grid, as in the example above.
Relationships.json
Relationships can be between two classes of different types (examples: Tunnel to Inspection, Tag to Task, Tag to Tag, Organization to Tag) or two classes of the same type (examples: Span to Deck, Tag to Tag, Document to Organization). In some WUIFPlugins there is a relationships.json file which defines how the application will present available relationships. For a key pair of routeId and templateId, there exist relationships that are relevant to when both that route and that template are in use. When applicable subtemplates will be shown in a container (example: a tab’s page).
The relationships.json provides extra information about which relationships and localized words to use, refresh behavior, and which templates to use in the container (details page in the master-detail design pattern ). The empty state template is shown in the container when a query response reports that there are no related instances. A relationship for a relationship tab varies depending upon context, so the route+template pair needs to have the empty state and default template defined.
The container is the details page in the master-detail design pattern.
EC Classes
When a form is created in Bentley Forms Designer, it is displayed on the base EC class to which it is mapped. To create a shared form, create it for a common base class.
The relationships.json configuration file is intended to be used with EC classes, not AssetWise classes. Therefore, when configuring parentClasses and relationshipClasses, be sure to use the EC names from the generated EC schema.
Special Case: Conditions to Tags; Conditions to Tasks
There is a relationship-like "Applies to" property. It works like a foreign key that points to an instance of another type (similar to the "instanceId" of a different objectType).
For example, if a Condition instance needs to be related to a Span instance (a child class of Tag), in AssetWise, the "Applies to" property is defined for the Condition class. "Applies to" is an intrinsic AssetWise property. Similar to Domain Attribute Definitions, it defines to which classes the Condition class can point. "Applies to" is a hierarchy sensitive property. It could be defined to allow Condition to point to Tag polymorphically which would allow Condition instances to point to an instance of any subclass of Tag.
Then AssetWise automatically tries to establish a Parent-Child relationship between the Parent Task and the child Task (assuming it exists, either explicitly or implicitly by way of polymorphism).